• • A 

.u. 

Assistant commissioner for patents attorney docket no. 12217-100 ^ 



lOi 



[Washington, d.c. 20231 Pa 9 e 1 of 3 



I CERT IF ZCAT ION UNDER 37 C.F .R. § 1.10 

:0 



I hereby certify that this New Application Transmittal and the 
documents referred to as enclosed therein are being deposited with 
the U.S. Postal Service on this date February 25, 1998 in an 
envelope as "Express Mail Post Office to Addressee" Mailing Label 
No . KM342694712US to the Assistant Commissioner for Patents, 
Washington, DC 20231. 

February 25, 1998 Thomas F. Presson — 

(Signature of Person Mailing Paper) 



APPLICATION TRANSMITTAL UNDER 37 C.F.R. § 1.53 

Transmitted herewith for filing under 37 C.F.R. § 1.53 is the patent 
application of: 

Inventors : Richard Kenneth Schultz 
Howard Kent Gilbert 
Ashish Suresh Deshpande 

for: 

1 . Type of Application 

[X] Original E ] Continuation [ ] Divisional 
[ 3 Continuation-In-Part 

2 . Benefit of Prior Foreign Appl ication fs) (35 U.S.C. — § 119) 

[ ] The new application being transmitted claims the benefit of 

[ ] prior foreign application Serial No. , filed 

on in (country) ; or 

[ ] PCT international application designating at least one 

country other than the U.S. application Serial No. , 

filed on • 

A certified copy is [ ] enclosed or [ ] on file in the prior 
application. 

3 . Benefit of Prior U.S. Application ( s) (35 U.S.C. § 120) 

[ ] The new application being transmitted claims the benefit of 

prior copending U.S. application (s) : Serial No. , 

filed on . 



ATTORNEWpOCKET NO. 12217-100 
Page 2 of 3 

4 . Papers Enclosed Which Are Required for Filing Under 37 C.F.R. § 

1.53 (b) 



[45] 


page(s) of Specification 


[153 


page(s) of Claims , having .59 claims, including S 
independent and J54 dependent claims 


[ 1] 


page(s) of Abstract 


[15] 


sheet (s) of [ ] formal [X] informal Drawings 



5 . Additional Papers Enclosed 

[ ] Preliminary Amendment 

[X] Information Disclosure Statement 

[X] Form PTO-1449 

[X] Copies of Cited Art 

[ ] Other „ 

6 . Declaration 

A declaration is [X] enclosed [ ] not enclosed. 

7 . Assignment 

[X] Enclosed are a recordation form and an assignment of the 
invention to Metaserver , a corporation of the State of 
Delaware. 

8 . Small Entity Status 

[X] A verified statement claiming small entity status: 
[X] is enclosed. 

[ ] as filed in prior application and such 

status is still proper and desired. 



9. Fee Calculation (37 C.F.R. S 1.16) 



CLAIMS AS FILED 


Number Number Rate Basic Fee 
Filed Extra $790.00 


Total Claims 


[59] 


-20 


39 


$22 . 00 


$858.00 


Independent claims 


[5] 


-3 


2 


$82 . 00 


$164 .00 


Multiple Dependent claims, if any: 


$270.00 


-o- 


Total 




$1812 .00 


Reduction for small entity by 5 0% 




$906.00 


TOTAL FILING FEE 




$906.00 



10 . Method of Payment of Fees 




[ ] Check in the amount of . 

[X] Charge Account No. 23-1665 in the amount of 5906 . 00 . 



ATTORI^^DOCKET NO. 12217-100 

Page 3 of 3 



11 . Authorization to Charge Additional Fees 

The Commissioner is hereby authorized to charge any additional fees 
that may be required under 37 C.F.R. §§ 1.16, 1.17, and 1.18, or 
credit any overpayment to Account No. 23-1665. 

12 . Correspondence 

Please address all correspondence to: 

Thomas F. Presson 

Intellectual Property Law Section 
WIGGIN & DANA 
One Century Tower 
New Haven, CT 06508-1832 
(203) 498-4503 




Thomas F. Presson 
Reg. No. 41,442 



WIGGIN & DANA 
One Century Tower 
New Haven, CT 06508-1832 
Date: February 25. 1998 (203) 498-4503 



12217\1\50278 . 01 



PATENTS 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Applicant (s) : Richard Kenneth Schultz Docket No.: 12217-100 
Howard Kent Gilbert 
Ashish Suresh Deshpande 

Serial No. : Not yet given Examiner: Not yet assigned 

Filed: Herewith Art Unit: Not yet assigned 

For: Method and Apparatus for Event Driven Processing of Data 



CERTIFICATE OF MAILING 

I hereby certify that this paper (along with any 
paper referred to as being attached or enclosed) is 
being deposited with the U.S. Postal Service on this 
date February 1998 in an envelope as "Express Mail 
Post Office to Addressee" Mailing Label No. EM342694712US 
to the Assistant Commissioner for Patents, Washington, 
DC 20231. 



Thomas F. Presson 



Date _ 



(Signature of Person Mailing Paper) 



VERIFIED STATEMENT AS SMALL ENTITY 

Assistant Commissioner for Patents 
U.S. Patent and Trademark Office 
Washington, DC 20231 

Dear Sir: 

[X] THE UNDERSIGNED DECLARE (S) : 

Exclusive rights in the above-identified invention reside in the 
"small entity (ies) " defined and named below, and "small entity" 
fees are appropriate. Qualification as a small entity is based 
upon the appropriately checked statements below. 



[ ] INDEPENDENT INVENTOR (S) 

The below-signing independent inventor (s) has (have) not assigned, 
granted, conveyed or licensed, and is (are) under no obligation 
under contract or law to assign, grant, convey or license any 
rights in the invention to any person who could not likewise be 
classified as an independent inventor under 37 C.F.R. 1 1.9(c) if 
that person had made the invention, or to any concern which would 
not qualify as a small business concern under 37 C.F.R. 1 1.9(d) or 
a nonprofit organization under 37 C.F.R. 1 1.9(e). 



# 




Page 2 of 3 
Docket No. 12217-100 



[X] SMALL BUSINESS CONCERN 

The below identified small business concern qualifies as a small 
business as defined in 13 C.F.R. 11 121.1301 to 121.1305, and 
reproduced in 37 C.F.R. 1 1.9(d), for purposes of paying reduced 
fees under Section 41 (a) and (b) of Title 35, in that the number 
of employees, including those of its affiliates, which does not 
exceed 500 persons, and it has not assigned, granted, conveyed or 
licensed, and is under no obligation under contract or law to 
assign, grant, convey or license, any rights in the invention to 
any person who could not be classified as an independent inventor 
if that person had made the invention, or to any concern under 27 
C.F.R. 1 1.9(d) or a nonprofit organization under 37 C.F.R. 1 
1.9(e) . 

Concerns are affiliates of each other when, either directly or 
indirectly, one concern controls or has the power to control the 
other, or a third party controls or has the power to control both. 

The number of employees of the business concern is the average 
over the fiscal year of the persons employed during each of the pay 
periods of the fiscal year. Employees are those persons employed 
on a full-time, part-time or temporary basis during the previous 
fiscal year of the concern. 



[ ] NONPROFIT ORGANIZATION (Check additional applicable 



The below-identified nonprofit organization qualifies as a small 
entity under 37 C.F.R. 1 1.9(e) in that it constitutes: 

[ ] a university or other institution of higher education 
located in any country; or 

[ ] an organization of the type described in Section 
501(c) (3) of the Internal Revenue Code of 1954 (26 U.S.C. 1 
501(c) (3)) and exempt from taxation under Section 501 (a) of the 
Internal Revenue Code (26 U.S.C. T 501(a)); or 

[ ] any nonprofit scientific or educational organization 
qualified under a nonprofit organization statute of a state of the 
United States (35 U.S.C. ' 201(D); or 

[ ] any nonprofit organization located in a foreign country 
that would qualify as a nonprofit organization under paragraphs 
(e) (2) or (3) of 37 C.F.R. ' 1.9 if it were located in the United 
States . 

The undersigned acknowledge ( s ) -the duty -to file, in -this 
application or patent, notification of any change in status 
resulting in loss of entitlement to small entity status prior to 
paying , or at the time of paying, the earliest of the issue fee or 
any maintenance fee due after the date on which status as a small 
entity is no longer appropriate (37 C.F.R. T 1.28(b)). 



box. ) 



• 



Page 3 of 3 
Docket No. 12217-100 



The below-signing individual (s) hereby declare (s) that (he, she 
they) are authorized to execute this statement on behalf of the 
small entity; that all statements made herein of (his, her, their) 
own knowledge are true and that all statements made on information 
and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United 
States Code, and that such willful false statements may jeopardize 
the validity of the application, any patent issuing thereon, or any 
patent to which this verified statement is directed. 



Name of Small Entity: 
Metaserver 



Address of Small Entity: (Street, City, State or Country, 
Zip Code) 

One Century Tower, 265 Church Street, New Haven, CT 06510 

Name of Person Signing: 

Richard Kenneth Schultz 

Title of Person Signing: 

OFFICER 



Signature: (Please sign and date in 
permanent i#k. ) 




Date signed: 



12217\1\53670.01 



Express Mail No. EM342 6 94 7 12US 
Docket No. 12217-100 

METHOD AND APPARATUS FOR EVENT -DRIVEN PROCESSING OP DATA 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to an event -driven data processing 
software system having multiple software modules for 
processing data in communication with one another. More 
5 particularly, this invention relates to a software system 
having a task module that executes self -modifying scripts, 
thereby invoking active responses from data processing modules 
based upon event data that is transmitted to the task module 
from other modules . 

10 

2 . Brief Description of the Background 

Conventional methodology for accessing network 
application data can be cumbersome. For example, in order for 
a client/user to access data from a network application, it is 
15 typically necessary for the network application and the 

application protocol to be modified to enable the client/user 
protocol to recognize them. This modification is inefficient 
because it necessitates the conversion of server application 




programs to another protocol in order to access data desired 
by the client. In other words, the network application and 
the client/user may not be able to communicate with each other 
because of different native applications or protocols. 
5 A second example of the cumbersome nature of conventional 

network interactions is illustrated by the fact that network 
applications and data are typically not dynamically updated 
based upon sequential or simultaneous activities or events 
that are taking place in other network applications. 

10 There have been attempts to address some of these 

inefficiencies and shortcomings. Unfortunately, as can be 
seen from the following discussion, these attempts fail to 
provide a means for dynamically processing data from a variety 
of network applications. 

15 U.S. Patent No. 5,325,527 (Cwikowski et al.) discloses a 

client/server communications system utilizing a self- 
generating nodal network. Each service node includes both 
process steps for advertising a service to the server root 
node and process steps for building a topic node which 

20 includes both process steps for accessing a server and process 
steps for building a job node in order to store job requests. 
The service nodes include steps for communicating with an 
application program and steps to create a job request in 
accordance with a job request designated by the application 

25 program. However, the Cwikowski et al . patent fails to 
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recognize the need for a system that receives data and 
utilizes self -modifying commands to gather additional data 
from a plurality of processors in order to "update" itself or 
to incorporate the additional data, much less to disclose a 

5 system that addresses such needs . 

U.S. Patent No. 5,325,530 (Mohrmann) discloses a 
controller for sequential programming tools executed in a 
parallel-computing environment. This controller executes 
sequential tools on an individual node of a parallel computing 

10 system. The controller associates each tool with a particular 
process of a user program executing on a particular node. In 
particular, the controller, in combination with various 
debugging tools operating on various nodes in the parallel - 
computing environment, produces a parallel program debugger. 

15 Unfortunately, the invention disclosed in the Mohrmann patent 
merely performs steps sequentially, and does not disclose a 
system that dynamically modifies steps that have yet to be 
performed. 

U.S. Patent No. 5,625,837 (Popescu et al . ) discloses a 
20 processor architecture having out-of-order execution, and 
speculative branching capabilities that give priority to 
instructions that affect a condition code. This process 
architecture uses instruction fetching functions that are 
decoupled from instruction execution functions by a dynamic 
25 register file. More specifically, the results of the executed 
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instructions are flushed from provisional storage, and the 
instruction previously executed at the beginning of a branch 
based upon predicted dependencies is re-executed based upon 
the actual data that subsequently becomes available. However, 
5 the Popescu et al . patent fails to disclose gathering 
processed data from a network, much less a system that 
dynamically incorporates the gathered processed data in order 
to "learn" from it. 

U.S. Patent No. 5,634,127 (Cloud et al.) discloses 
10 methods and apparatus for implementing a message driven 

processor in a client-server environment. This message driven 
processor operates as middleware between clients and back-end 
hosts or servers in a large client -server system to reduce the 
number of concurrent sessions required to be supported by the 
15 network and to allow a common client -user interface to 

divergent back-end systems. The Cloud et al . patent teaches a 
message queue for storing data but does not disclose mapping a 
message to a set of commands that is self -modifying, much less 
a system that incorporates gathered data into the system. 
20 U.S. Patent No. 5,689,708 (Regnier et al . ) discloses a 

client/server computer system that controls a) client-based 
application programs and b) application-programs. A resource 
manager and a client/server computer network control the 
availability of system resources. A system administrator 
25 generates a set of profiles that specifies which system 
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resources each user may employ for each of multiple 
application programs. The Regnier et al . patent discloses 
resource management, but does not disclose that the resource 
management capabilities interact with multiple databases to 
5 gather processed data for use in the system. 

As can be seen from the illustrative background discussed 
above, there is a need in the computer-programming field for a 
data processing system that 1) has the capability to receive 
requests from a variety of applications, which operate in a 

10 variety of environments, and 2) provides an appropriate 

response. The present invention provides a solution to that 
need in the form of an event -driven data processing system 
that utilizes series of self -modifying commands to receive 
event data signals and to generate an appropriate response, 

15 and updates the self -modifying commands in response to the 
event data. 
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SUMMARY OF THE INVENTION 

In one aspect, the present invention relates to a 
software system that enables event modules to transmit event 
data to a task module, which utilizes a script, or a series of 
5 instructions, to respond to the event data. The task module 
executes the series of instructions necessary to generate 
response data. The instructions executed in the script are 
dynamically modified based on the results of data gathered by 
the script . The task module executes the script by performing 
10 processing on, and potentially gathering data from, requisite 
processing modules. A response profile can be generated that 
represents the combined or cumulative results of the series of 
instructions. Upon completion of the series of instructions, 
the response profile can be assembled from the response data, 
15 and transmitted from the task module to an application program 
or a user, which is typically the originating event module. A 
response profile is transmitted only in situations in which a 
response is necessary. 

In another aspect, the present invention relates to a 
20 data processing system stored on a computer-readable medium. 
This system comprises : 

one or more event modules for generating event data 
signals representative of a particular event; 

one or more scripts each of said one or more scripts 
25 having one or more instructions; 
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one or more processing modules for providing said one or 
more scripts with processed data; 

a task module, communicating with each of said one or 
more event modules, for executing a selected one of said one 
5 or more scripts that corresponds to said event data signals; 
whereby during said execution, said selected script 
interfaces with one or more of said one or more processing 
modules based upon said one or more instructions and said 
selected script incorporates the results of said interfacing 
10 into said one or more instructions of said selected script. 

This invention can further include a resource management 
module in direct communication with said one or more event 
modules, said task module and said one or more processing 
modules for dynamically assigning processing functions to said 
15 one or more processing modules; and 

an administrative module in direct communication with 
said task module, said one or more event modules, said one or 
more processing modules and said resource management module, 
for receiving and presenting data relating to said one or more 
20 processing modules. 

In still another aspect, the present invention relates to 
a method of data processing. This method comprises the steps 
of: 

generating event data signals at one or more peripheral 
25 modules; 
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transmitting said event data signals from said one or 
more peripheral modules to a task module; 

receiving, at said task module, said event data signals 
transmitted from said one or more peripheral modules; 
5 mapping, at said task module, said event data signals to 

a selected script of one or more scripts, each said one or 
more scripts having one or more instructions for performing 
data gathering steps; and 

executing, by said task module, said selected script to 
10 gather processed data from one or more of said one or more 
peripheral modules ; 

wherein during said execution, said selected script 
dynamically incorporates results of said executing into said 
one or more instructions, thereby affecting said data 
15 gathering steps . 

In still another aspect, the present invention relates to 
an event-driven data processing system. This system 
comprises : 

generating means for generating event data signals; 
20 transmitting means communicating with said generating 

means for transmitting said event data signals; 

converting means communicating with said transmitting 
means for recognizing the event data signals and mapping said 
event data signals to a selected set of self -modifying process 
25 steps; 
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executing means for executing said selected set of self- 
modifying process steps; 

processing means for providing processed data to said 
executing means; and 
5 incorporating said processed data into said selected set 

of self -modifying process steps thereby determining the manner 
in which said selected set of self -modifying process steps is 
executed. 

In yet still another aspect, the present invention 
10 relates to a process for generating a plurality of operational 
commands for gathering data for storing on a computer- readable 
medium. This process comprises: 

collecting inputs from at least one source of 
inf ormat ion ; 

15 processing the inputs to generate at least one set of 

self -modifying commands that can be executed; and 

utilizing the executed set of self -modifying commands to 
respond to an event data signal. 

These and other aspects of the present invention will 
20 become apparent upon reading the following detailed 
description of the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram of the event data processing system 
in accordance with the present invention. 

Figure 2 shows a plurality of modules that may be used in 
5 the present invention. 

Figures 3A-3F illustrate the self -describing features of 
the present system. 

Figure 4 is a flow chart of event data processing in 
accordance with this invention. 
10 Figure 5 shows the relationship between the task module, 

processing modules, event data generating modules and network 
peripherals . 

Figure 6 shows an embodiment by which the peripheral 
modules can communicate with one another. 
15 Figures 7A and 7B illustrate protocol interface 

configurations between peripheral modules and the task module. 

Figures 8A and 8B illustrate the event data processing 
steps of this invention using a specific example. 
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DETAILED DESCRIPTION OF THE INVENTION 

It has been found in accordance with the present 
invention that data received from various applications in a 
data processing system can be used to access a series of self- 
5 modifying instructions. The self -modifying instructions 

perform steps required to process the data received. After 
the first instruction of the series is executed, the remaining 
instructions may be modified based upon the results of the 
execution of a previous instruction. This method is repeated 

10 with respect to the second instruction and, by repeated 

iterations the system "learns" by virtue of data provided from 
previous instructions . 

The present invention describes a software system that 
can coordinate a plurality of software modules such that data, 

15 generated by a processing module or a user/client module, may 
be employed by a task module to perform processing. The task 
module is suitably employed to generate a response to the data 
generated in a situation in which a response is required or 
desired. The software modules are programs, and/or 

20 subprograms, and/or functions within programs, or any 

combination of programs, subprograms and functions within 
programs (generally referred to as "code"). The modules are 
suitably stored in a computer- readable , and/or computer- 
writeable media. The system may optionally be fabricated 
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using conventional computer hardware and/or optionally- 
fabricated from a combination of hardware and software. 

The software architecture of the present invention may be 
described in terms of a hub and spoke module system. 
5 Peripheral modules represent spokes and include 1) event 

modules, such as a user station that inputs request data, and 
2) processing modules, such as application programs. A task 
module to coordinate events and processing represents the hub. 
The task module is in single-directional or bi- 
10 directional communication with at least one peripheral module 
and typically a plurality of peripheral modules. The task 
module can be employed to substantially simultaneously and/or 
sequentially interface with a plurality of peripheral modules 
to receive event data and process the received data. 
15 The task module uses data transmitted from the event 

modules to access a script . Each script contains a series of 
preprogrammed commands, which may require interfacing with 
processing modules when executed. The execution includes 
creation of a response profile that addresses event data. The 
20 task module executes the instructions by invoking actual 

processing or processing modules, and by gathering data from 
the necessary processing modules. The requisite processing 
modules depend upon the commands in the script . The task 
module incorporates information gathered from each of the 
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processing modules and thereby updates and modifies the set of 
instructions in a self -describing fashion. 

The script may have a memory that dynamically keeps track 
of modifications to the script itself. As the steps are being 
5 performed, affected application programs receive accurate and 
dynamic information regarding the status of other processing 
modules and result data generated. The script incorporates 
the information into the instructions and thereby modifies the 
action taken by the script. 

10 Figure 1 shows the event-data processing system 10 having 

a task module 12 0 and examples of peripheral modules in 
communication with the task module. The functions of event 
generating module 105, processing/event generating module 106, 
responder module 175, administrative module 170, status 

15 monitoring module 174, load balancing module 173, storage 135 
and converter module 155 will be described in detail in the 
discussion of Figure 2 . 

It should be noted that the communication between modules 
in system 10 may be either bi-directional or single- 

20 directional depending on the type of data being transmitted 
between the modules. 

Figure 2 shows the system 10 in greater detail. The task 
module 12 0 is in communication with a plurality of event data 
generating modules 105 (1) ... (n) , a plurality of processing 

25 modules 106 (1) ... (n) , and 107(l)...(n) (n being an arbitrary 
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integer), a converter module 155, storage 135, a responder 
module 175, a resource management module 172, a load balancing 
module 173, a status -monitoring module 174, and an 
administrative module 170. It should be noted that the 
5 modules of this embodiment are not all necessary parts of the 
invention, but they provide the context in which the preferred 
embodiment will be described. 

Task Module 

Task module 120 is suitably employed to receive event 
10 data from one or more event modules 105 (1) ... (n) , and may 
optionally receive event data from one or more processing 
modules 106 (1) ... (n) . The task module 120 utilizes scripts 
121(l)...(n) (n being an arbitrary number), that can be stored 
in storage 135. These scripts 121(1)... (n) are comprised of a 
15 series of instructions and/or commands. Upon execution of the 
script, the instructions are used to direct the steps the 
script takes to gather data. These scripts 121(1)... (n) 
correspond to particular event data received by the task 
module 12 0. 

20 The scripts 121 (l).„(n) are retrieved by the task module 

120. The task module 120 executes the retrieved script e.g. 
121(1). The particular script e.g. 121(1) invokes required 
ones of processing modules 106(1)... (n) and 107(1)... (n) to do 
processing and to gather data from those modules. These 

25 scripts 121(l)...(n) enable the task module 120 to respond to 



14 



9 



particular event data received by interfacing with or 
"visiting" a requisite number of processing modules 
106 (1) ... (n) , 107 (1) ... (n) . The processing modules I06(l).„(n) and 
107(1)... (n) perform the necessary processing to provide the 
5 task module 12 0 with the desired data. 

Each script 121(1)... (n) is executed to perform the 
instructions and/or commands programmed into that script . 
Upon gathering data from a particular processing module, the 
steps to be executed may change based upon the data gathered 

10 from the processing modules. The execution of a script 

121(l)...(n) utilizes the gathered data to modify the next step 
in the script. The task module 120 can execute a plurality of 
scripts I2l(l)...(n) substantially simultaneously. 

The task module 120 is programmed to invoke available 

15 processing modules to respond to a data request. Therefore, 
if any one of the processing modules 106 (l)...(n) , I07(i)...(n) is 
occupied at the time the task module 12 o seeks to invoke that 
module, the task module will route the request to an available 
processing module that can process the request or, if there 

20 are not any processing modules available, wait for the next 
available processing module, thus providing load-balancing of 
modules in the system 10 . 

The task module 12 0 is in communication with processing 
modules 106 (1) ... (n) , 107 (1) ... (n) , event modules 10 5 (1) ... (n) , 

25 converter module 155, resource management module 172, load 
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balancing module 173, status monitoring module 174, responder 
module 175, script building module 13 6, and storage module 
135. Task module communication with these modules may be bi- 
directional or single-directional, depending upon the type of 
5 data being transmitted. This enables the task module 120 to 
transmit and/or receive data from each of these modules. 

It should also be noted that the task module is able to 
interface with multiple modules in parallel such that more 
than one module in the system 10 may be in communication with 
10 the task module 120 at one time. Parallel processing of data 
facilitates communication between peripheral modules through 
the task module since the task module 12 0 can be 
simultaneously transmitting and receiving data. This feature 
reduces the amount of time required to execute scripts 
15 121(l)...(n) because multiple steps in a script can be executed 
substantially simultaneously. Parallel processing also 
prevents modules in the system 10 from being affected by the 
failure of a particular module because the task module 12 0 
will not access a malfunctioning or non- functioning module in 
20 system 10. The task module 120 receives information relating 
to the operating status of modules in the system 10 from 
status monitoring module 174, which keeps track of modules 
that have failed or are malfunctioning and proceeds so as to 
avoid interaction with such modules. This insulates the other 
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peripheral modules in the system 10 from interfacing with a 
failed module. 

It is possible for the system 10 to include a plurality 
of task modules. Running a plurality of task modules 
5 substantially simultaneously is advantageous to facilitate 
increased event-driven data processing capabilities and fault 
tolerances . 

The task module 12 0 may also include a tracing module 18 5 
that performs the function of storing the status of the data 
10 gathering and processing procedure when a script e.g. 121(1) 
is executed. Thus, if a processing module experiences 
failure, the script 121(1) and processing already completed by 
script 121(1) will not be lost and processing can continue 
without interruption. The tracing module 185 increases the 
15 reliability of the system 10. This status -monitoring feature 
is inherent in the task module, but may also be programmed 
into a separate module in communication with the task module. 

As the task module 120 executes a particular script 
121(1), the results of the execution form a response profile 
20 that may be stored in the script 121(1) and/or may be stored 
in storage 13 5. When the last step of the script 121(1) has 
been executed, the complete response profile may be stored in 
storage 135 or transmitted to a user location, such as event 
module 105(1), or discarded. 
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Event Modules 

Event modules 105(1)... (n) are in communication with task 
module 12 0. Event modules 105(1)... (n) generate data relating 
to a particular event or request. Examples of events include 
a request to purchase an item from a Web browser, the status 
of a database, the status of inventory, that a database needs 
attention, etc. This information is transmitted to a task 
module 120, which is in communication with the event modules 
105 (1) ... (n) , and receives the event data from the event modules 
105 (l)...(n) . Event modules 105(l)...(n) are not used by system 
10 to perform data processing. Examples of event modules 
105(l)...(n) include portable software that can run on a variety 
of hardware devices such as user terminals, personal computers 
or back office machines running a variety of operating 
systems . 

Event data can also be generated by processing modules 
106(1)... (n) . These modules can both process data and generate 
event data. Both types of modules 105(l)...(n) and 106(l)...(n) 
can receive signals from task module 12 0 representing a 
response to event data. 

Processing Modules 

Processing modules 106(1)... (n) and 107(1)... (n) are in 
communication with the task module 12 0 such that they can 
receive signals that request processing and data. Processing 
modules 106(1)... (n) and 107(1)... (n) also transmit processed data 



18 



to the task module 120. Examples of processing modules 
106(1)... (n) and 107 ( 1 ) ... (n) include various application programs 
such as databases, client-server applications, network 
applications and server applications. Processing modules 
5 106(1)... (n) and 107(1)... (n) are not required to be dedicated and 
may be in communication with network application peripherals 
or systems outside system 10. 

One difference between processing modules 106(l)...(n) and 
107(l)...(n) is that processing modules 106 ( 1) ... (n) , in addition 

10 to being modules capable of performing data processing, are 

also capable of generating event data in a fashion similar to 
event modules 105 (1) ... (n) . 

For example, processing module 106(1) may be an inventory 
database that processes requests, received from task module 

15 120, to retrieve the quantity of a particular item in 

inventory. When running with an event module, the processing 
module 106(1) may also generate event data, such as the fact 
that inventory has been depleted below a pre- specif ied 
quantity. Module 106(1) can then transmit that data to the 

20 task module 120 because it has dual functionality of event 
generation and data processing. The processing modules 
106(l)...(n) may be in communication with a corresponding client 
module 113 (1) ... (n) , which can facilitate event generation 
interfacing with the task module 12 0. Other examples of 
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processing modules 106(l)...(n) include network applications, 
network servers and main frame applications. 

Processing modules 107(l)...(n) do not include an event 
module and therefore do not generate event data, but may 
5 merely exchange information to the task module 12 0 upon 
interfacing the task module 120. This interfacing can be 
facilitated by the use of an associated initiator module 
166 (l)...(n) . 

Initiator Modules 
10 Initiator modules 165(l)...(n) and 166(l)...(n) may be 

disposed between task module 120 and processing modules 106 
and 107 (l)...(n) , respectively, (i.e., initiator modules 
165(1)... (n) are associated with modules I06(l).«(n) and 
initiator modules 166(1)... (n) are associated with modules 
15 107 (l)...(n) ) . Initiator modules 165(l)...(n) and 166(l)...(n) 
translate data signals sent between task module 120 and 
processing modules 106(l)...(n) and 107 (1) „.(n) . The initiator 
modules 165 (1) ... (n) , 166(l)...(n) may be built into the 
associated processing module. Alternatively, initiators 
20 165(l)...(n) and 166(l)...(n) may be separate modules that store 
information pertaining to the corresponding processing module 
106(l)...(n) and 107(1)... (n) respectively. For example, 
initiator 165(1) could maintain accumulated data related to 
processing module 106(1). Initiator 165(1) can interface with 
25 the task module 12 0, and enable the task module 12 0 to derive 



20 




and gather information related to processing module 106(1) 
without examining all of the contents in processing module 
106(1) . Thus, the task module 120 may merely interface with 
the corresponding initiator module i.e., 165(1) and thereby 
5 gather all the necessary information. Likewise, the task 
module 120 may use the initiator modules 165(l)...(n) and 
166(l)...(n) to transmit information to associated processing 
modules 106(l)...(n) and 107 (1) ... (n) , respectively. 

Client Modules 

10 Interfacing between the task module 12 0 and event modules 

105(1)... (n) and 106(l)...(n) (note that processing modules 
106(l)...(n) may also perform event data generation) may be 
corresponding client modules 112(l)...(n) and 113 (1) ... (n) , 
respectively (n being an arbitrary integer) . Client modules 

15 112(l)...(n) and 113(l)...(n) may be used to translate and store 

event data that is transmitted to the task module 12 0 from the 
modules 105(l)...(n) and 106(l)...(n) or response data that may be 
transmitted from the task module 120 to the modules 105(1)... (n) 
and 106 (1) ... (n) . Examples of client modules 112(l)...(n) and 

20 113(l)...(n) include C++ clients, JAVA clients (JAVA is a 

registered trademark of Sun Microsystems, Inc. of Mountain 
View, California) , ACTIVE X clients (ACTIVE X is registered 
trademark of Microsoft Corp. of Redmond, Washington) and Web 
clients . 
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Protocols 

Additionally, between the client modules 112 (1) ... (n) and 
task module 120 may be protocols 115(1)... (n) (n being an 
arbitrary integer). Each client module I12(l)...(n) may 
5 interface with a corresponding protocol 115{l)...(n) that is 

between the client module 105(1)... (n) and the task module 120. 
As can be seen from Figure 2, the protocols 115(l)...(n) may be 
between the task module 120 and the corresponding event module 
105 (1) ... (n) . In a similar fashion, protocols 116(l)...(n) are 

10 associated with a corresponding processing module 106 (1) ... (n) . 
Protocols 117(l)„.(n) may be associated with corresponding 
processing modules 107 (1) ... (n) . Protocols 115 (1) ... (n) , 
116(l)„.(n) and 117(l)...(n) may be standard protocols or non- 
standard protocols . Examples of standard protocols include 

15 COM (COM is a registered trademark of Microsoft Corp. of 

Redmond, Washington) , JAVA BEANS (JAVA BEANS is a registered 
trademark of Sun Microsystems, Inc. of Mountain View, 
California) , Corba and TCP/IP. 

The protocols 115 (1) ... (n) , 116(1)... (n) and 117(1)... (n) 

20 enable the task module 12 0 to communicate with other 

peripheral modules in system 10 regardless of the manufacturer 
or native application of a particular peripheral module or 
network hardware and software . 
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Converter Module 
Converter module 155 is in communication with the task 
module 12 0 and receives event data from the task module 12 0 
(this event data was received by the task module 12 0 from 

5 another module in system 10) for the purpose of performing a 
mapping function. The converter module 155 recognizes event 
data and maps specific event data to a particular script, or 
set of instructions 121 (1) ... (n) , to respond to the received 
event data. Once a particular script, e.gr. 121(1), is mapped 

10 to a particular event, the converter 155 transmits the 

appropriate signal so that the task module 120 can "fetch" or 
retrieve the appropriate script, e.gr. 121(1) from storage 135. 
It should be noted that although only one converter module 155 
is shown in Figure 1, there could be a plurality of converter 

15 modules used in system 10 . 

Script Building Module 
Script building module 13 6 may be used to construct a 
script or to modify an existing script. The script, or set of 
instructions 121 (1) ... (n) , performs a desired function in 

20 response to event data. The set of instructions may be a 
series of commands or a single command. Examples of 
instructions included in a script are running a process such 
as a database, "If ... then ... else" statements, and standard 
flow charting steps to perform a particular task. Programming 

25 a script in this fashion enables the script to dynamically 
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change based upon the commands that have been executed. Thus, 
upon performing the first instruction in a script e.g. 121(1), 
the script 121(1) will receive data. The data received will 
be incorporated into the script 121(1) and will determine how 
5 the script 121(1) proceeds. 

The script building module 13 6 may generate scripts 
121(l)...(n) through a graphical user interface or a programming 
interface. This programming interface may be a language level 
interface that generates a plurality of operational commands. 
10 When executed, the commands of the scripts I21(l)...(n) perform 
processing on, and gather information from, processing modules 
106(l)...(n) and 107 (1) ... (n) . The commands of the scripts may 
also interface with event modules 105(1)... (n) and 106(1)... (n) to 
collect event data. Thus, once the script building module 13 6 
15 generates the commands, the commands may then be executed by 
the task module 12 0. 

Once a script, e.g. 121(1), has been created by the 
script building module 136, it may be accessed at a later 
time. The script building module 136 also enables a script 
20 created earlier to be modified by retrieving a script and 
revising it to include commands that were not previously 
included or to remove commands that are no longer desired. 
The scripts 121 (1) ... (n) , after being created, may be saved in 
storage module 135. System 10 may utilize a plurality of 
25 script building modules . 
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Storage Module 
Storage module 135 may be in communication with all of 
the modules of system 10 directly or via task module 12 0. The 
storage module 13 5 may be, for example, any form of computer- 
5 writeable media, computer- readable media, and/or memory bank. 
If a memory bank is utilized, all modules on a network can 
communicate with each other through that memory. Specific 
examples of computer-writable and readable media include 
floppy disk, hard disk and memory. The storage module 135 can 

10 include any size memory and is only limited by the amount of 
storage available on the computer containing the storage 
module. Storage module 13 5 has the capacity to store data 
pertaining to the operation of any of the modules in system 
10. For example, storage module- 13 5 may store scripts 

15 121 (1) ... (n) , and may also store scripts that are being executed 
by the task module 12 0, as well as resource management data 
from resource management module 172, system administration 
data from administrative module 170, status monitoring data 
from status -monitoring module 174, load -management data from 

20 load balancing module 173 and responder module data from 

responder module 175. Furthermore, storage module 135 may act 
as a queue, storing event data that has not been processed by 
task module 12 0. Storage module 13 5 may also store result 
data that is gathered by the execution of scripts 121 (1) ... (n) . 
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Responder Module 
Responder module 175 is in communication with the task 
module 12 0 and provides a translation function on the response 
data generated by the task module 12 0, as a result of 

5 execution of a script 121 (1) ... (n) . The responder module 175 
outputs a response profile, which may be transmitted via the 
task module 12 0 or transmitted directly from the responder 
module 175 to the event modules 105 (1) ...(n) , 106 (1) ».(n) , in a 
format that the event modules 105 (1) ... (n) , 106(l)...(n) can 

10 recognize , 

Resource Management Module 
Resource management module 172 is used to dynamically 
allocate processing module function of processing modules 
106(1)... (n) and 107(1)... (n) based on information received from 

15 task module 12 0. The resource manager module 172 keeps track 
of the assigned functionality of processing modules 106(l)...(n) 
and 107(1)... (n) . The resource managing module is in bi- 
directional and single-directional communication with the task 
module 12 0 and keeps track of the nature of the event data 

20 being received by task module 12 0. The resource management 
module 172 may also be in direct communication with other 
peripheral modules such as event modules 105(1)... (n) and 
processing modules 106(l).„(n), 107 (1) ... (n) . 

The resource managing module 172 monitors system 

25 information such as how many processing modules are available 
for a particular task, the amount of event data that has not 




been processed, and the load average and statistics concerning 
the processing modules 106(l)...(n) and 107 (1) ... (n) . The 
resource managing module 172 allocates processing module 
function based upon dynamic system needs. This enables the 
5 task module 120 to operate more efficiently since the 

availability of processing modules 106 (1) ... (n) , 107(l)...(n) that 
can perform the required tasks is maximized. An example of 
this is a situation in which processing modules 106(1) and 
107(1) perform selling features. When an increased number of 

10 purchase requests are received, the resource managing module 

172 can convert modules 106(1) and 107(1) from selling modules 
to purchasing modules. This provides more purchasing modules 
to perform processing for the task module 120. 

Administrative Module 

15 Administrative module 170, which is in communication with 

the task module 12 0, receives data from the task module 12 0 
relating to system maintenance and storage ability. 
Alternatively, the administrative module can be in 
communication with any other module in the system 10 directly. 

20 The administrative module is programmed to allow users to 
start and stop data processing activities and keep track of 
activities of the modules in system 10. The administrative 
module 170 also presents accumulated data to enable proper 
maintenance of system 10. For example, administrative module 

25 170 could be a software program that outputs messages 
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regarding the status of processing modules 106 (1) ... (n) , 
107 (1) ... (n) . Administration module 170 can also start and stop 
initiators 165(1)... (n) and 166(1)... (n) and thereby control the 
operation of the system 10. 

5 Load Balancing Module 

Load balancing module 173 is a peripheral module in 
communication with the task module 12 0 and may be in direct 
communication with other peripheral modules. Load balancing 
module 173 monitors the contents of task module 120, storage 

10 module 135 and processing modules 106(l)„.(n) and 107 ( 1) ... (n) . 
The function of load balancing module 173 is to determine 
which processing modules 106(1)... (n) and 107(1)... (n) are 
available to receive processing requests. This enables 
processing modules 106(l)...(n) and 107(l)...(n) that are not busy 

15 to receive requests required by task module 120 and, thereby, 
provide for more efficient operation of system 10. The load 
balancing module 173 could run on task module 12 0 or be a 
separate module 173. 

Status Monitoring Module 
20 Status monitoring module 174 is in communication with the 

task module 120, and may be in direct communication with the 
other modules of system 10. The status monitoring module 174 
monitors the operational status of each processing module 
106 (1) ... (n) , 107(l)...(n) to ensure that a processing request is 
25 not sent to an inoperative processing module by task module 
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12 0. Status monitoring module 174 also has storage to save 
the current status of a script 121(1)... (n) that is being 
executed. If a script e.g. 121(1) is interfacing with a 
processing module and that processing module fails, the script 
5 121(1) will not be lost. Rather, the status monitoring module 
174, which stores each script being executed, enables the task 
module 12 0 to continue the execution of the script from the 
last command executed. The status monitoring module may store 
the particular script in storage within the status monitoring 
10 module or in storage module 135. This feature adds 

reliability and efficiency to system 10 since if a processing 
module fails, it will not disturb the execution of a script. 

Additionally, the status monitoring module 174 will not 
access a failed processing module, but will communicate with 
15 the task module 12 0 so that only properly functioning 

processing modules are accessed. The status monitoring 
functions may run on the task module 12 0 or may be a distinct 
module 174 . 

Thus, as shown in Figure 2, the system 10 may be 
20 described as a hub-and-spoke configuration of software modules 
with a task module 12 0 in communication with peripheral 
modules 105 (1) ... (n) , 106 (1) ... (n) , 107 ( 1) ... (n) , 155, 135, 136, 
170, 172, 173, 174 and 175 that perform specific functions. 
The system 10 also includes client modules 112(1)... (n) and 
25 113 (l)...(n) and initiator modules 165 (1) ... (n) , 166{l)...(n) to 
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facilitate interfacing with associated peripheral modules. 
Protocols 115 (l)...{n) , 116(l)...(n) and 117(l)...(n) may also be 
used between the task module 12 0 and corresponding peripheral 
modules. It should be noted that although Figure 2 shows an 
embodiment using only one of certain modules, the system 10 
may have a plurality of any of the modules for faster and more 
reliable performance. 

Figure 3A shows how a particular script 121(1) may be 
implemented by task module 12 0. Event data is received by 
task module 120, for example, from an event module 105(1) . 
The task module 120 then interfaces with converter module 155, 
which performs a mapping function of the received event data 
to a script that will respond to the event data. The task 
module 12 0 then retrieves the corresponding script, for 
example, 121(1) from storage 135. Storage 135 may be used to 
store a plurality of scripts 121 (1) ...(n) . 

Figure 3B shows that the task module 12 0 has retrieved a 
script 121(1) that lists a series of steps to be performed. 
Once the script, or series of instructions, 121(1) has been 
retrieved from storage 135, the task module executes the 
script by interacting with requisite processing modules. 
(This interacting may be done substantially simultaneously or 
sequentially depending on the nature of the data being 
gathered by the script 121(1).) For example, database 1 
(106(1)), spreadsheet (106(2)) and database 2 (106(3)) may be 
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the data required to respond to a particular event and 
therefore are the steps for the script 121(1). If the system 
10 was an electronic commerce system, database 1 could be 
inventory, spreadsheet could be a spreadsheet calculation to 
5 create an invoice and database 2 could be the payment system. 
As seen in Figure 3C, the task module 12 0 has already 
performed interfacing with initiator 165(1) (not shown) and 
has gathered data from processing module 106(1) (not shown), 
which is database 1. The gathered information from database 
10 1, (106(1)), may be stored in storage module 135 and/or may 
also be stored in the script 121(1) as 106(1)'. Interfacing 
with database 1 required the script 121(1) to perform the 
necessary commands based on the logic programmed into the 
script 121(1). The script 121(1) utilizes the results of the 
15 commands when performing the next instruction in the script 

121(1), which is gathering data from spreadsheet 106(2). Task 
module 120 proceeds to interface with initiator module 165(2) 
at database spreadsheet (106(2)) since that is the next 
instruction of script 121(1). The preprogrammed series of 
20 instructions 121(1) performs a list of desired functions in a 
specified manner. The set of instructions 121(1) in the task 
module 12 0 is iterative in nature and responds to information 
received by the previous instruction. Thus, the task module 
120 will utilize information 106(1)' received from database 
25 106(1) (as shown in figure 3B) and information received from 
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spreadsheet (106(2)) when interfacing with database 2 
(106 (3) ) . 

Referring back to Figure 3B, since task module 12 0 is in 
parallel communication with a plurality of processing modules 
5 106 (1) ...(3) , the task module 120 is receptive to event data 
transmitted by any of these processing modules. Task module 
120 can access any peripheral module substantially 
concurrently to send or receive information. The task module 
12 0 only waits to transmit data if the necessary data has not 
10 been received from another prerequisite peripheral module. 

In the example that processing module 106(1) is the 
inventory of a product, and that inventory exceeds a pre- 
specified quantity, an event data signal may be transmitted 
from processing module 106(1) to task module 120 via client 
15 module 113(1). Task module 120 receives this data and 

converter 155 recognizes this event data and maps it to a 
corresponding script, for example, script 121(2). Task module 
120 then executes the script 121(2), thereby interfacing with 
the requisite processing modules to respond to the event that 
20 inventory in 106(1) exceeds a pre-specif ied quantity. This 
series of instructions 121(2) might be to access another 
processing module, for example 106(4) (not shown), which could 
be the price database. The result of this may be that task 
module 12 0 sends a signal to lower the price for that 
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particular item. The task module 12 0 can execute a plurality 
of scripts 121(1)... (n) substantially simultaneously. 

Additionally, in a situation in which the quantity of 
inventory was depleted below a specified number, a processing 
5 module 106(1) (inventory database) could send a signal to the 
task module 120 via client module 113 (l) . This data would be 
recognized as event data and a signal would be sent to the 
converter module 155 for the converter 155 to map the event 
data to a script 121(3) (not shown). The script 121(3) would 
10 include commands to respond to a depleted inventory situation. 
The task module 120 would execute script 121(3) to respond to 
the event that inventory is depleted. One step could be that 
the task module 12 0 transmits a signal to a status monitoring 
module (not shown) , which could inform a user that inventory 
15 is low and additional inventory is required. Thus, the task 
module 12 0 has the capability to access a script for every 
recognized event. The quantity and type of script utilized is 
based on event data received. 

In a slightly different example as shown in Figure 3D, 
20 involving a processing module 107(1) which can process data 
but cannot generate data, the task module can nonetheless 
utilize results generated by that processing module 107 (1) . 
When event data is generated, by event module for example, 
105(2), task module 120 will receive the data and, via the 
25 converter 155, implement a series of instructions 121(4). If 
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one of the instructions necessitates task module 12 0 invoking 
processing module 107(1), task module 120 will interface with 
processing module 107(1). Upon interfacing with processing 
module 107(1) the task module 120 will gather information and 
5 use that information to modify the series of instructions 
121(4) . Task module 120 will use the data gathered from 
107(1) when it interfaces with processing module 106(3), which 
is the next command in the script 121(4). Thus, the script 
121(4) utilizes the data gathered in the previous steps when 
10 executing the next step until the execution is complete. 

Upon completion of a particular script, the task module 
12 0 can store the results of the script execution in storage 
135. The task module 120 may also generate a response if one 
is required. 

15 Figure 3E shows that in some instances, event modules 

require a response to the event data transmitted to the task 
module. In these situations, upon completion of a series of 
instructions, the task module 120 assembles all of the data 
gathered from the required processing modules. If a response 

20 is desired, the script being executed accumulates information 
and, generally, as the last step of the script, the task 
module 12 0 interfaces with responder module 175 and provides 
the responder module 175 with a response profile 176, which 
represents the results of the execution of a script. 

25 Responder module 175 formats the response profile 176 into a 
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format that the event module 105(5) can understand, for 
example a Web browser that recognizes HTML, and the task 
module 120 transmits the response profile 176 to the event 
module 105(5) in that format. Alternatively, the responder 
5 module 175 can interface directly with the event module 105(5) 
and provide the response profile 176 to the event module 
105(5) without interfacing with the task module 120. 

Figure 3P shows that a script is mapped to received event 
data. The task module 120 receives event data 205 from, for 
10 example, event module 105(6), and utilizes converter 155 to 

match the event data 205 to script retrieval data 210 that can 
respond to the event data 205. Once a script has been 
determined, the task module will retrieve that script e.g. 
121(6) from storage 135. 
15 The task module 12 0 has the ability to execute a 

plurality of steps in a script substantially simultaneously, 
as well as execute a plurality of scripts substantially 
simultaneously to respond to a plurality of event data. 

Figure 4 shows a flow chart of steps that may be used to 
20 implement one example of the event driven data processing 

system. In step 3 01 a request is made by a user, such as a 
user request to place an order for a hat from a remote 
location through the Internet. This request is recognized as 
an event and event data is generated, which could be to 
25 process the order, in step 3 02. This event data is 
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transmitted to a task module and the transmission can be 
facilitated by a client module. The task module is in 
communication with a converter module that translates the 
event data generated and maps the event data to an appropriate 
5 script in step 303. The task module then retrieves the 
designated script from the storage module in step 304. 
Execution of the script and interfacing with the processing 
modules required to accumulate response data to respond to the 
event data is performed in step 305. 
10 It should be noted that if the processing steps are 

independent, the task module will substantially simultaneously 
execute the commands in the script. 

The task module coordinates the execution of the script 
such that the processing modules can perform the necessary 
15 processing. As the task module executes the script, the data 
in the task module itself is modified and updated based upon 
the data gathered through the execution of the script as shown 
in step 306. These script steps may include, for example, 
ordering a desired quantity from inventory, determining the 
20 price, and processing payment for the order. 

An example of executing a script would be that the first 
instruction to be executed is ordering the desired quantity 
from inventory. The task module interfaces with the 
processing module that has inventory information and gathers 
25 inventory data. If the inventory is depleted, the script will 
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use that information during the further execution of the 
script. For example, logic statements programmed into the 
script enable the script to use the depleted inventory- 
information to respond to the user. Such a response could be 
5 a message that although the inventory of hats is insufficient, 
other items are on sale, such as gloves or socks. The script 
may also be programmed to execute a series of commands to 
generate a rain check for the user in a depleted inventory 
situation. 

10 Thus, the script is programmed to dynamically respond to 

data received from each of the processing modules that the 
script interfaces with. 

If the inventory is adequate to fill the request, this 
information is gathered in the script, and the script proceeds 

15 to the price processing module, where price data is gathered 
for the quantity of hats ordered. The task module includes 
the quantity of inventory when it gathers data from the price 
module and calculates the price. 

Thus, after the price is gathered from the price 

20 processing module, the script proceeds to the payment module. 
In this module, information about the payment method, such as 
a credit card account number which the purchaser provided to 
the system, is processed. If such information is determined 
to be invalid, the script will execute a series of steps such 
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as asking for another account number, advising the user that 
the credit card is invalid or some other appropriate response. 

The data gathering and processing steps are continued 
until the requisite instructions are completed as shown in 
5 decision block 307. 

Once the task module has completed all the required steps 
in the script, the gathered data may be formatted into a 
desired format and output to specified modules. However, if 
the script does not have a response step, the accumulated data 
10 may be stored in a storage module, or otherwise disposed of. 
The transmission of the accumulated data to a module is shown 
in box 3 08 . 

Figure 5 shows an embodiment of the system 10 that 
includes network application peripherals in communication with 

15 event modules and processing modules. Processing modules 

106(1)... (n) and 107(1)... (n) and event modules 105(1)... (n) are not 
required to be dedicated, and therefore, these modules may 
have associated network application peripherals. 

As shown in Figure 5, event module 105(1) can have 

20 associated network application peripherals 193(1)... (n) (n being 
any integer). Processing modules 106(1) and 107(1) can have 
associated network application peripherals I96(l).„(n) and 
194 (1) ... (n) , respectively. Examples of network application 
peripherals include databases, transaction systems, and order 

25 entry systems. Protocols 415(1)... (n) and 416(1)... (n) may be 
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used to facilitate interfacing between corresponding modules 
105(1)... (n) and 106(1)... (n) respectively , and network 
application peripherals. Network application peripherals 
193 (1) ... (n) , 194 (1) ... (n) , and 196(l)...(n) can communicate with 

5 their respective systems (e.gr. 105 (1) ... (n) , 107 (1) ... (n) , and 
106 (1) ... (n) ) independently of system 10 or task module 120. 
The task module 120 treats modules 105 (1) ... (n) , 106(l)...(n) and 
I07(l)...(n) as though the network application peripherals 
193 (1)... (n) , 194 (1)... (n) , and 196(l)...(n) were non-existent. The 

10 task module 120 does not get information directly from the 
network application peripherals 193 (1) ... (n) , 194(l)...(n) and 
196(l)...(n) but merely gathers information from modules 
105 (l)...(n) , 106(l)...(n) and 107 (1) ... (n) . 

Modules 105 (l)...(n) , I06(l)...(n) and 107 (1) ... (n) , with their 

15 associated network application peripherals 193 (1) ... (n) , 
196 (l)...(n) , and 194 (1) ... (n) , are viewed as autonomous 
independent systems. For example, module 106(1) may be part 
of a separate order production system that is functioning 
without any communication with task module 120. The module 

20 106 (1) has network application peripherals 196(l)...(n) by which 
module 106(1) performs processing. The task module 120 is 
designed to access modules such as 106(1) and use the data in 
that module to perform other operations. 

Figure 6 shows an example of how peripheral modules may 

25 be in communication with each other, as well as in 
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communication with the task module 120. The spoke-and-hub 
configuration with peripheral modules in communication with 
each other permits the peripheral modules to transmit and 
receive data from one another without necessarily involving 
5 the task module 12 0. 

As shown in Figure 6, resource management module 172 can 
interface with processing module 106(1) and gather information 
related to the function of processing module 106(1) . Load 
balancing module 173 can then interface with both processing 
10 module 106(1) and resource management module 172 and thereby 
determine where to send the next request for a particular 
script being executed by task module 120. Administrative 
module 170 can interface directly with processing module 
106(1) and event module 105(1) to determine when event data is 
15 generated by event module 105(1) or 106(1) without necessarily 
utilizing task module 120. 

Thus, the configuration as shown in Figure 6 enables a 
plurality of peripheral modules to directly interface with 
each other. This can provide a more efficient system in those 
20 circumstances in which the task module 12 0 does not need to be 
involved with every interface between peripheral modules . 

The modules shown in Figure 6 are merely examples of 
modules that can communicate directly with other modules. The 
invention is not limited to only those modules illustrated in 
25 Figure 6 . 
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Figure 7A shows one type of interface between task module 
120 and processing module 107(1). The initiator module 166(1) 
may be running on the same computer as processing module 
107(1)- In this situation protocol 117(1) may interface with 
5 task module 120 and module 607, which includes initiator 
module 166(1) and processing module 107(1). An example of 
protocol 117(1) is TCP/IP. A second protocol 717(1) may 
interface between the initiator module 166(1) and the 
processing module 107(1). An example of protocol 717(1) is 
10 inter-process communication, possibly through shared memory. 
Figure 7B shows a second type of communication link 
between task module 120 and processing module 107(1) . In this 
embodiment processing module 107(1) and initiator module 
166(1) are not running on the same computer. Task module 120 
15 can communicate with processing module 107(1) through two 

protocols 117(1) and 717(1). Protocol 117(1) interfaces with 
task module 120 and initiator module 166(1) . The type of 
protocol may be, for example, TCP/IP. 

As can be seen, the initiator module 166(1) may be 
20 running on a separate machine from the processing module 

107(1) and utilize a second protocol 717(1), which interfaces 
with initiator module 166(1) and processing module 107(1). 
Protocol 717(1) may be, for example, Corba, TCP/IP, COM (COM 
is a registered trademark of Microsoft Corp. of Redmond, 
25 Washington) . 
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It should be noted that a protocol interface arrangement 
as described in Figures 7A and 7B may also be used between the 
task module and other peripheral modules. For example, a 
client module could be substituted for the initiator module 
5 with an event module being substituted for the processing 
module. It should also be noted that the modules in system 
10, although illustrated as discreet modules, could also be 
combined to run on the same computer. 

The following discussion uses Figures 8A and 8B to 
10 illustrate a possible implementation of the present invention. 
This discussion is intended to illustrate, but in no way limit 
the scope of the present invention. 

As shown Figure 8A box 801 , a user at a personal computer 
may log onto an electronic commerce system, offering a wide 
15 variety of products for sale. The user logging onto the 
system is received by the task module as event data. This 
event of a user logging on is mapped to an appropriate script 
in box 802. The appropriate script is retrieved from storage 
in box 8 03 . 

20 The retrieved script is then executed in box 8 04. The 

execution requires performing the instructions programmed onto 
the retrieved script. 

The first instruction of the script may be to check if a 
customer database is operational as shown in box 805. This 

25 can be done by interfacing with a status -monitoring module. 
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If the database is not operational, the script may wait for 
the database to become operational or attempt to access 
another database. If the database is operational, the next 
instruction in the script might be to check a database of 

5 customer listings to determine if this user has logged onto 
the system previously as shown in box 810. A processing 
module could be a database that stores identification of users 
who have logged onto the system in the past . 

If the user is a new customer, a step in the script could 

10 be to display available products to the user as shown in box 
811. 

If upon interfacing with the customer listing database 
the user is identified as a repeat visitor, the script will 
then use the fact that the user is a repeat customer to gather 
15 an identification number associated with that particular user 
as shown in box 812. 

As shown in Figure 8B, the next step could be to 
interface with or "visit" a prior purchase database, as shown 
in box 815, which could be a database that stores information 
20 relating to prior purchases of particular users. The script 
would utilize the user identification information gathered 
from the previous processing step to gather information 
relating to prior purchases of the particular user. It may be 
that this user has purchased outdoor products that are red- 
25 colored in the past. This step is shown in box 82 0. 
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The next instruction in script could be to interface with 
or "visit" a processing module that could be an inventory 
database, as shown in box 825. The script could provide the 
prior purchasing information, such as the fact that this user 

5 has previously purchased red-colored outdoor products , to the 
inventory database to determine what products in inventory are 
outdoor products or red- colored products and whether the 
quantity of any of those products exceeds a particular number. 
After gathering inventory data in box 825, the script may 

10 then "visit" a pricing database in box 83 0 with the gathered 

information. The script could include a command to reduce the 
price on items gathered from visiting the inventory database. 

The next step in the script could be to provide a listing 
of available products in inventory that are red- colored or 

15 outdoor products to the user and note that these products are 
being offered to the user at a reduced price. This listing of 
products that the user may be interested in purchasing, based 
on prior purchases could be transmitted to the user, as shown 
in box 840. 

20 Thus, one embodiment of the present invention can be the 

generation of a specific list of products a user may be 
interested in purchasing whenever the user logs onto an 
electronic commerce system. 

While this disclosure describes particular embodiments of 

25 the invention, it is to be understood that the invention is 



44 



# • 

capable of use in various other combinations or modifications 
within the scope of the inventive concept as expressed herein. 
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WHAT IS CLAIMED IS ; 

1. A data processing system stored on a computer- readable 
medium comprising: 

one or more event modules including code that generates 
an event data signal representative of a particular event; 
5 one or more scripts each of said one or more scripts 

having one or more instructions; 

one or more processing modules each including code that 
provides processed data to said one or more scripts; and 

a task module, selectively communicating with each of 
10 said one or more event modules, including code for execution 
of a selected one of said one or more scripts that corresponds 
to said event data signal; 

wherein during said execution, said selected script 
interfaces with one or more of said one or more processing 
15 modules and incorporates results of said interfacing into said 
one or more instructions of said selected script. 

2. The system as claimed in claim 1, wherein said task 
module executes a plurality of said one or more scripts 
substantially simultaneously. 
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3. The system as claimed in claim 2 further comprising: 
a converter module, in communication with said task 

module, including code that maps said event data signal to one 
or more of said plurality of said one or more scripts upon 
reception of said event data signal by said task module. 

4. The system as claimed in claim 1 wherein said one or more 
processing modules provide event data signals, representative 
of a particular event, to said task module. 

5. The system as claimed in claim 1 further comprising: 

a status monitoring module, in communication with said 
task module, including code that provides information to said 
task module relating to operating conditions of said one or 
more processing modules. 

6 . The system as claimed in claim 5 wherein said status 
monitoring module is in direct communication said with said 
one or more processing modules. 

7. The system as claimed in claim 5 wherein during said 
execution of said selected script, said status monitoring 
module stores data associated with said selected script in an 
associated memory. 
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8. The system as claimed in claim 1 further comprising: 

a load balancing module, in communication with said task 
module, including code that dynamically selects available ones 
of said one or more processing modules to perform processing. 

9. The system as claimed in claim 8 wherein said load 
balancing module is in direct communication with said one or 
more processing modules. 

10. The system as claimed in claim 1 wherein said task module 
interfaces with said one or more processing modules for bi- 
directionally and substantially simultaneously transmitting 
data between said one or more processing modules and said task 
module . 

11. The system as claimed in claim 1 further comprising: 

a resource management module, in communication with said 
task module, including code that dynamically assigns 
processing functions to said one or more processing modules. 

12 . The system as claimed in claim 11 wherein said resource 
management module is in direct communication with said one or 
more processing modules, 
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13. The system as claimed in claim 1 further comprising: 
one or more initiator modules including code that 

provides a communication interface between an associated one 
of said one or more processing modules and said task module. 

14 . The system as claimed in claim 13 wherein each of said 
one or more initiator modules communicates with said 
associated one of said one or more processing modules 
regardless of native applications contained on said associated 

5 one of said one or more processing modules. 

15. The system as claimed in claim 13 further comprising: 
a protocol disposed between each of said one or more 

initiator modules and said task module for providing a 
communication interface therebetween. 

16. The system as claimed in claim 13 further comprising: 
a protocol disposed between each of said one or more 

initiator modules and said associated one of said one or more 
processing modules for providing a communication interface 
5 therebetween. 
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17. The system as claimed in claim 1 further comprising: 

one or more client modules including code that provides a 
communication interface between an associated one of said one 
or more event modules and said task module. 

18. The system as described in claim 17 further comprising: 
a protocol disposed between said task module and each of 

said one or more client modules for providing a communication 
interface therebetween . 

19. The system as claimed in claim 17 further comprising: 
a protocol disposed between each of said one or more 

client modules and said associated one of said one or more 
event modules for providing a communication interface 
5 therebetween. 

20. The system as claimed in claim 1 wherein each of said one 
or more scripts is preprogrammed to iteratively update its 
contents . 

21. The system as claimed in claim 1 further comprising: 

a storage module, in communication with said task module, 
for providing storage for said system. 
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22. The system as claimed in claim 21 wherein said storage 
module comprises a computer- readable medium. 

23. The system as claimed in claim 22 wherein said computer 
readable medium comprises a persistent memory. 

24. The system as claimed in claim 21 further comprising: 
a script building module, in communication with said 

storage module, including code that creates said one or more 
scripts . 

25. The system as claimed in claim 24 wherein said script 
building module includes a standard language interface. 

26. The system as claimed in claim 24 wherein said script 
building module includes a graphical user interface. 

27. The system as claimed in claim 24 wherein said script 
building module dynamically updates and modifies said one or 
more scripts . 

28. The system as claimed in claim 1 further comprising: 
a protocol for providing a communication interface 

between said task module and each of said one or more event 
modules . 
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29. The system as claimed in claim 1 further comprising: 
a protocol for providing a communication interface 

between said task module and each of said one or more 
processing modules, 

30. The system as claimed in claim 1 further comprising: 
a responder module, in communication with said task 

module, including code that transmits response data, resulting 
from said execution, from said task module to particular said 
5 one or more processing modules or to particular said one or 
more event modules. 

31. The system as claimed in claim 1 further comprising: 

an administrative module, in communication with said task 
module, including code that receives and presents data that 
relates to said one or more processing modules. 

32. The system as claimed in claim 1 further comprising: 

one or more application peripherals in communication with 
an associated one of said one or more processing modules or an 
associated one of said one or more event modules. 
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33. A data processing system stored on a computer-readable 
medium comprising: 

one or more event modules each including code that 
generates an event data signal representative of a particular 
5 event ; 

one or more scripts each of said one or more scripts 
having one or more instructions; 

one or more processing modules each including code that 
provides said one or more scripts with processed data; 
10 a task module, selectively communicating with each of 

said one or more event modules, including code for execution 
of a selected one of said one or more scripts that correspond 
to said event data signal; 

wherein during said execution, said selected script 
15 interfaces with one or more of said one or more processing 

modules and incorporates results of said interfacing into said 
one or more instructions of said selected script; 

a resource management module in direct communication with 
said one or more event modules, said task module and said one 
20 or more processing modules, including code that dynamically 
assigns processing functions to said one or more processing 
modules; and 

an administrative module in direct communication with 
said task module, said one or more event modules, said one or 
25 more processing modules and said resource management module, 
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including code that receives and presents data relating to 
said one or more processing modules . 

34. A method of data processing comprising the steps of: 

generating at least one event data signal at one or more 
peripheral modules ; 

mapping, said at least one event data signal to a 
5 selected script chosen from one or more scripts, each said one 
or more scripts having one or more instructions for performing 
data gathering steps; and 

executing, by a task module, said selected script to 
gather processed data from one or more of said one or more 
10 peripheral modules; 

wherein during said executing step, said selected script 
dynamically incorporates results of said executing into said 
one or more instructions of said selected script. 

35. The method as claimed in claim 34 wherein said one or 
more peripheral modules and said task module communicate via a 
communication interface. 

36. The method as claimed in claim 34 further comprising the 
step of : 

dynamically managing operating functions of said one or 
more peripheral modules. 
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37. The method as claimed in claim 34 further comprising the 
steps of : 

producing response data signals as a result of said 
executing step; and 
5 transmitting said response data signals from said task 

module to selected said one or more peripheral modules. 

38. The method as claimed in claim 37 further comprising the 
step of: 

translating said response data signals transmitted from 
said task module into a format that said selected said one or 
5 more peripheral modules recognize. 

39. The method as claimed in claim 38 further comprising the 
step of: 

storing said event data signals, said one or more scripts 
and said response data signals in a storage medium that is in 
5 communication with said task module. 

40. The method as claimed in claim 39 wherein said storage 
medium is persistent. 
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41. The method as claimed in claim 34 further comprising the 
step of: 

accessing a protocol to interface between said task 
module and selected said one or more peripheral modules. 

42 . The method as claimed in claim 34 further comprising the 
step of: 

providing communication between said task module and each 
of said one or more peripheral modules such that said task 
5 module will access only ones of said one or more peripheral 
modules capable of performing processing operations. 

43. The method as claimed in claim 34 wherein said executing 
step includes the step of : 

interfacing with a plurality of said one or more 
peripheral modules substantially simultaneously. 

44. The method as claimed in claim 34 wherein said executing 
step executes a plurality of said one or more scripts 
substantially simultaneously. 
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45. The method as claimed in claim 34 further comprising the 
step of: 

programming said one or more scripts such that said one 
or more instructions will be executed based upon a previously 
executed instruction . 

46. The method as claimed in claim 34 further comprising the 
step of: 

providing results of said executing step to an 
administrative module for presenting information relating to 
said one or more peripheral modules . 

47. An event-driven data processing system comprising: 
generating means for generating event data signals; 
converting means for recognizing the event data signals 

received and mapping said event data signals to a selected set 
of self -modifying process steps; 

executing means for executing said selected set of self- 
modifying process steps; 

processing means for providing processed data to said 
executing means; and 

wherein results of said executing means are incorporated 
into said selected set of self -modifying process steps, 
thereby determining the manner in which said selected set of 
self -modifying process steps is executed. 
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48. The data processing system as claimed in claim 4 7 further 
comprising : 

responding means communicating with said executing means 
for generating response signals based upon results of said 
5 executing means. 

49. The data processing system as claimed in claim 48 further 
comprising: 

storage means for storing data generated by said 
generating means, said processing means, said converting 
5 means, said executing means and said responding means. 

50. The data processing system as claimed in claim 48 further 
comprising: 

second transmitting means in communication with said 
responding means for transmitting said response signals to a 
5 utilization location. 

51. The system as claimed in claim 50 wherein the utilization 
location includes at least one processing module. 

52. The system as claimed in claim 50 wherein the utilization 
location includes at least one event module. 
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53. The system as claimed in claim 4 7 further comprising: 
administrative means for controlling said event-driven 

data processing system. 

54. The system as claimed in claim 47 further comprising: 
managing means for dynamically modifying operating 

functions of said processing means. 



55. The system as claimed in claim 47 further comprising: 

means for determining operational status of said 
processing means. 



56. The system as claimed in claim 47 further comprising: 

programming means for programming said one or more sets 
of self -modifying process steps. 



57. The system as claimed in claim 47 further comprising: 

controlling means for controlling said executing means 
such that said executing means will not interface with said 
processing means when said processing means are not available 
5 to perform processing. 



58. The system as claimed in claim 47 wherein said executing 
means substantially simultaneously executes a plurality of 
said one or more sets of self -modifying process steps. 
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59. A process for generating executable operational commands 
for gathering data comprising the steps of: 

collecting inputs from at least one source of 
information; 

5 processing the inputs to generate at least one set of 

self -modifying commands that can be executed; 

storing said at least one set of self -modifying commands 
in a computer-readable medium; and 

selectively executing one or more of said at least one 
10 set of self -modifying commands in response to an event data 
signal . 
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Docket No* 12217-100 



METHOD AND APPARATUS FOR EVENT DRIVEN PROCESSING OF DATA 



A data processing system that enables event modules to 
transmit event data to a module capable of processing the 
event data, generating a response, and when required producing 
a response profile to be sent to a location. The response is 
produced by the system executing one or more scripts to 
perform processing and gather data from processing modules. 
As the response is being generated by the execution of the 
script, the scripts self -modify based upon the data gathered. 
The system recognizes the necessary changes and dynamically 
generates a response to the changes. If the response profile 
must be transmitted to another location, the response profile 
will be in a format that the receiving location will 
recognize . 
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COMBINED DECLARATION AND POWER OF ATTORNEY FOR JOINT INVENTORS 

1. As below named joint inventors, we hereby declare that our addresses 
and citizenship are as stated below next to our names . We believe we 
are the original, first, and joint inventors of the subject matter 
which is claimed and for which a patent is sought on the invention 
entitled: 

METHOD AND APPARATUS FOR EVENT-DRIVEN PROCESSING OF DATA 

the specification of which: 
[X] is attached or 

[ ] was filed on as Serial No. and 

amended on . 

2 . We hereby state that we have reviewed and understand the contents of 
the above-identified specification, including the claims, as amended by 
any amendment referred to above. 

3 . We acknowledge the duty to disclose information which is material to 
the patentability of this application in accordance with Section 
1.56(a) of Title 37, Code of Federal Regulations. 

4. [ ] Because this is a continuation-in-part application, we acknowledge 

our duty to disclose to the Office all information known to us to 
be material to the patentability as defined in 37 C.F.R. § 1.56 
which has become available between the filing date of the prior 
application and the filing date of this continuation-in-part 
application. 

5. [ ] We hereby claim foreign priority benefits under Title 35, United 

States Code, § 119 of any foreign application (s) for patent or 
inventor's certificate or of any PCT international application (s ) 
designating at least one country other than the United States of 
America listed below and have also identified below any foreign 
application (s) for patent or inventor's certificate or any PCT 
international application (s) designating at least one country 
other than the United States of America filed by us on the same 
subject matter having a filing date before that of the 
application (s) of which priority is claimed: 



Country 


Application 
Serial No. 


Date of Filing 
(day, mo., yr.) 


Priority Claimed under 35 
U.S.C. § 119 
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6. [ ] We hereby claim the benefit under Title 35, United States Code, 

§ 120 of any United States application (s) that is/are listed below 
and, insofar as the subject matter of each of the claims of this 
application is not disclosed in that/those prior application (s) in 
the manner provided by the first paragraph of Title 35, United 
States Code, § 112, we acknowledge the duty to disclose material 
information as defined in Title 37, Code of Federal Regulations, 
§ 1.56(a) which occurred between the filing date of the prior 
application (s) and the filing date of this application: 



Application Serial No. 


Filing Date 


Status 















7 . We hereby declare that all statements made herein of our own knowledge 
are true and that all statements made on information and belief are 
believed to be true; and further that these statements were made with 
the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of 
Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent 
issuing thereon. 

8. As named inventors, we hereby appoint the following attorneys of Wiggin 
& Dana to prosecute this application and transact all business in the 
Patent and Trademark Office connected therewith: Dale L. Carlson, Reg. 
No. 2 8,784; Todd E . Garabedian , Ph . D . , Reg . No . 39,197; Thomas F . 
Presson, Reg. No. 41,442; Gregory S. Rosenblatt, Reg. No. 32,489; and 
William A. Simons, Reg. No. 27,096. 

9. Please send all correspondence to: 

Thomas F. Presson 

Intellectual Property Law Section 

Wiggin & Dana 

One Century Tower 

New Haven, CT 06508-1832 

Telephone: (203) 498-4503 

10. [3 As named inventors, we hereby appoint the attorney listed in 

paragraph 9 as our domestic representative for the invention 
identified in paragraph 1 with full power of substitution and 
revocation, to transact all business in the U.S. Patent and 
Trademark Office and in the U.S. courts in connection therewith. 
He is also designated as domestic representative on whom process 
or notice of proceedings affecting the application or patents 
issuing therefrom may be served. 
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[X] We hereby authorize the U.S. attorney named in paragraph 9 to 

accept and follow instruction from metaserver as to any actions 
to be taken in the U.S. Patent and Trademark Office regarding this 
application without direct communication between the U.S. attorney 
and us. In the event of a change in the person from whom 
instructions may be taken, we will notify the U.S. attorney. 

11. Inventor Information: 

Pull name of first joint inventor Richard Kennetft jchultz 

Date Z*$/ Citizenship USA 

Residence 5 Stonewall Lane, Woodbridge, CT 06525 
P.O. Address 5 Stonewall Lane. Woodbridge, CT 06525 




Inventor's signature ( 



Full name of second joint inventor Howard Kent Gilbert 
Inventor's signature „ 
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Citizenship USA 



Residence 386 St. Ronan Street. Mew Haven, CT 06511 
P.O. Address 386 St. Ronan Street, Hew Haven, CT 06511 



Pull name of third joint/inventor Ashish Suresh Deshpande 



Inventor's signatu-re 



Date 
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Residence 7 Pepperbush Lane, Guilford. CT 06492 
P.O. Address 7 Pepperbush Lane, Guilford, CT 06492 
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